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(57) Abstract: An intermediate network element deployed in a 
content delivery network is disclosed. The content delivery net- 
work cooperates its content delivery effort with other intermediate 
network element with similar capabilities. Distributing rules that 
govern the operations of the intermediate network element(s) are 
presented. These include the framework of the intermediate net- 
work element(s), the format of indicating part or whole of a rule 
specification to be distributed, the format of signatures for interme- 
diate network elements to discover each other, the format of signal- 
ing other intermediate network elements that a rule is distributed 
to, and the method of determining the intermediate network ele- 
ment to distribute a rule to. In addition, authoring rules that are 
specific to real time streaming of contents are disclosed. A set of 
rule evaluation conditions are revealed that can be triggered based 
on different criteria during the streaming of real time contents. A 
set of parameters from which rules can be based on is disclosed. 
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DESCRIPTION 

Method and Apparatus for Configuring and Controlling Network 
Resources in Content Delivery with Distributed Rules 

5 

Technical Field 

The invention relates to the field of content delivery in a 
data communications network. More particularly, this invention 
pertains to the distributed control of data packets stream 
10 flowing through an intermediate network element, and the 
distributed control and configuration of network resources at a 
hierarchy of the intermediaries. The main intended use of this 
invention is to act as a proxy for content streaming, and 
providing content adaptation services in a distributed manner. 

15 

Background Art 

Over the past decade, the Internet, or more specifically, 
the Internet Protocol (IP) based network, has seen a 
tremendous growth. The proliferation of the Internet and the 

20 increasing number of Internet users has resulted in extension 
and scaling problems for applications. This is especially true 
for applications designed for end-users, such as the World 
Wide Web (WWW), and audio-visual streaming. The increased 
in network bandwidth and processing power can hardly catch up 

25 with the demands of the increasing number of Internet users. 
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This has resulted in longer load time for WWW page request, 
and lost of quality in real-time audio-visual playback across the 
Internet. The effort to reduce such undesirable effects has led 
to a wide deployment of intelligent network elements at the 
network edge (i.e. nearer to the end-users). 

The most common use of such intermediate network 
elements are to function as caching proxies, such as hyper text 
transfer protocol (HTTP) proxies and/or caches as described in 
an article "Hypertext Transfer Protocol - HTTP/1.1", IETF RFC 
2616, June 1999, by Fielding, R., Gettys, J., Mogul, J., Frystyk, 
H., Masinter, L. , Leach, P., and T. Berners-Lee. These have 
been successful in reducing the network load at the WWW 
server and accelerating WWW contents delivery to the end- 
users. However, as the number of end-users increases, the 
15 variety of web-browser configurations and platforms widens. 
Similarly, the range of web contents is also broadening. Simply 
replicating static web contents cannot hope to sustain the ever- 
increasing demands from the end-users. 

In addition, there has also been a noted increase in the 
deployment of multimedia streaming over the Internet. These 
usually employ the real-time streaming protocol (RTSP) as 
session protocol to set up and tear down communications 
channel, and real-time transport protocol and real-time control 
protocol (RTP/RTCP) for the actual transmission of content 
data. The RTSP is disclosed for example, in "Real Time 
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Streaming Protocol (RTSP)°. IETF RFC 2326, April 1998, by 
Schulzrinne, H., Rao, A., and Lanphier, R. The RTP/RTCP is 
disclosed for example, in "RTP: A Transport Protocol for Real- 
Time Applications", IETF RFC 1889, January 1996, by 
5 Schulzrinne, H., Casner, S., Frederick, R., and Jabcobson, V. 
Because of the versatile nature of Internet traffic, adaptation of 
the multimedia stream to the fluctuating traffic conditions is 
necessary to ensure a smooth presentation to the end-user. 
Though RTCP provides a means for end-users to report their 
10 communication status back to the sender, measures taken up by 
the sender based on receiver report can hardly be effective 
because the distance (network-sense) between the receiver and 
sender is often large. As most end-users connects to the 
Internet via an intermediary of some sort, for instance, firewall 
15 gateways, Network Address Translator (NAT), or proxies, the 
intermediary present a good choice to perform adaptation 
services on behalf of the content originator. 

Furthermore, as the Internet grows, so does the range of 
devices that are used to access contents from the Web. This 
20 diversification of browser types has been accelerated with 
recent advancements in wireless Internet technology, whereby 
tiny handheld devices such as digital personal assistants (PDA) 
and mobile phones have micro-browsers built in that browse the 
web, or playback audio/visual streams. No longer can content 
25 authors develop contents with the assumption that the created 
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content will only be viewed by users using traditional desktop 
computers. Device independence is now a critical 

consideration, as disclosed in "Device Independence Principles", 
W3C Working Draft, http://www.w3.org/TR/di-princ/, September 

2001, by Gimson, R., et. al.,. 

A number of international standardization organisations 
have recognized the need to provide services originally 
available only at the network core (where the servers are 
located) to the network edge (where the end-users are located). 
For instance, the Internet Engineering Task Force (IETF) has 
recently set up a few working groups focusing on providing 
services at the network edges. The Open Pluggable Extensible 
Services (OPES) working group is one such effort. The OPES 
working group focuses on extending the current HTTP proxies 
from performing simple caching task to a whole suite of 
adaptation services. The framework of OPES is specified in "A 
Model for Open Pluggable Edge Services", IETF Internet Draft, 
Work In Progress, http://www.ietf.org/internet-drafts/draft- 
tomlinson-opes-model-01, November 2001. by Tomlison, G., 
Chen, R., and Hofmann, M. There is also a Content 
Distribution Internetworking (CDI) working group that 
concentrates on the collaborations between different content 
distribution networks (CDN). Such collaboration efforts are 
believed to be able to further accelerate the delivery of 
25 contents to the end user. 
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The current use of intermediaries in content delivery is 
mostly restricted to providing simple functionality such as HTTP 
caching, HTTP proxy, or RTSP proxy. This cannot hope to 
maintain the service level demanded by the users of today's 
5 Internet, as the number of end-users increases exponentially. 
Moreover, with the range of hardware devices and software 
agents employed to retrieve contents by different users are 
also broadening, content providers are finding it difficult to 
present to the users a coherent set of contents are that suited 
10 to the user's device and preferences. 

Though various international bodies have recognized the 
above problems, and have acted to provide resolutions, their 
work could still be improved on. The OPES framework 
described in focused on the operations of a single intermediary, 
15 ignoring the current trend of collaborations between content 
delivery networks. In addition, though the idea of the OPES 
framework is to perform content adaptation so as to enhance 
the user experience in content retrieval, it focused only on 
parameters of the HTTP. This is not only inadequate for device 
independence, it also does not cater to the growing number of 
audiovisual streaming applications. 
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Disclosure of Invention 

To solve the problem listed in section 3.3, the present 
invention allows content providers, access providers, and/or 
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end-users to specify rules governing the delivery of content via 
intermediate network elements. These rules can be distributed 
to other intermediaries along the content flow path, to achieve 
the maximum efficiency and easier control of network resources. 

5 It is suitable for deployment by different content delivery 
networks, and can cooperate among one another. In addition, 
the current invention allows rules to be specified that are 
specially catered for real time content streaming. The present 
invention also defines a mechanism to extend rules to be 

10 construct based on user preferences, and device capabilities. 
Such a provision allows the rule author to construct rules that 
can better adapt contents to achieve device independence. 

This invention involves the operations of one or more 
intermediate network elements performing content delivery and 

15 adaptation between end-users and the content providers. The 
intermediate network element (also known as intermediary) will 
parse each data packets transferred between the end-user and 
the contents provider. When the data packets matches certain 
criteria as specified by a set of rules registered with the 

20 intermediary, actions specified in the rules are carried out, 
usually results in the modification of the data packets. Rules in 
an intermediary can be distributed to other intermediaries which 
are more suited to evaluate the rule and/or perform the 
adaptations. In addition, rules can also cater specially to real 

25 time streaming protocol, or be constructed with delivery context 
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parameters to achieve device independence. 

Brief Description of Drawings 

Fig. 1 is a framework of an Intermediate Network Element, 
5 showing the functional architecture of the intermediate network 
element as used in the invention. 

Fig. 2 shows nodes along the Content Path, and illustrates 
a typical content flow path from the content server to the 
content user, traversing a single or plural number of 

10 intermediaries. 

Fig. 3 shows example of ContentPath Structure, 
particularly showing the values stored in a ContentPath 
structure of the intermediary foo4.bar.com as marked by literal 
204 in Fig. 2. 

15 F ig. 4 shows a method of Extracting Intermediaries 

Information from Embedded Signature in Data Packets, 
particularly showing the flow diagram of the method to extract 
intermediaries' signatures in the data packets to 
construct/update the ContentPath structure. 

20 Fig. 5 shows a method of Determining the Remote 

intermediary to Distribute Rule, particularly showing the 
algorithm used to determine the remote intermediary to 
distribute a rule to, given the distribution indication. 

Fig. 6 shows a method of Parsing Rule with Distributed 

25 Rule Support, particularly showing the algorithm used to parse 



^PbT/JP03/03140 

i 

8 



WO 03/078459 




10 



a rule with the focus on supporting distributed rules. The 
actually method of parsing the rule to check for syntactical 
validity and evaluation of the rule is outside the scope of this 
docu ment. 

Fig. 7 shows a method of Determining the Remote 
Intermediary to Distribute Rule in a Server-Client Model, 
particularly showing the algorithm used to determine the remote 
intermediary to distribute a rule to, given the distribution 
indication, in a server-client model. 



Best Mode for Carrying Out the Invention 

An apparatus and methods for distributed network 
resource management is disclosed. To facilitate understanding 
of the invention, the following definitions are used: 
15 A "packet" is a self-contained unit of data of any possible 

format that could be delivered on a data network. 

An "intermediary" and an "intermediate network element" 
are equivalent, and are used interchangeably, unless otherwise 
specified, to refer to a gateway, a router or an intelligent 
20 network hub for which this invention applies to. 

The term "current intermediary" or "current intermediate 
network element" refers to an intermediate network element 
that is processing a data packet, or a rule specification, 
depending on the context the term is used in. 
25 The terms "content server" and "content user" are used 
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with respect to a sever-client model of information exchange. 
The content user, which is the client, will send a single or 
plural number of data packets to the content server containing 
a request. Such data packets are known as request packets. 
5 The content server upon processing the request would reply 
with a single or plural number of data packets containing the 

response. Such data packets are referred to as response 

packets. 

In distribution of rules, the term "target intermediary" or 
10 "target intermediate network element" refers to the intermediate 
network element of the current invention receiving the 
distributed rule. The term "distributing intermediary" or 
"distributing intermediate network element" refers to the 
intermediate network element of the current invention 
15 distributing the rules to other intermediaries. 

In the following description, for purpose of explanation, 
specific numbers, times, structures, and other parameters are 
set forth in order to provide a thorough understanding of the 
present invention. However, it will be apparent to anyone 
20 skilled in the art that the present invention may be practiced 
without these specific details. 

The intermediate network element for which the current 
invention applies to, consists of the functional architecture as 
depicted in Fig. 1. The intermediary consists of a gateway 
25 module (101), a rule engine (102), a single or plural number of 
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special packages (103), and the rule injection module (104). 

The gateway module (101) is the collection of functional 
blocks that implement gateway or proxy functionalities. These 
can include, but not limited to, HTTP proxies and/or caches. 
RTSP proxies, RTP/RTCP mixers and/or translators, and 
application level gateways (ALG). For instance, we consider an 
intermediary performing the role of a HTTP proxy. The gateway 
module (101) would thus implements the functional component 
to handle HTTP connections from the client side, the functional 
components to establish a HTTP connection to the server, or 
another HTTP proxy, based on the client side request, and the 
functional component to relay responses from the server back 
to the client side. Effectively, the gateway module (101) is the 
functional component that implements the protocols (eg HTTP, 
15 RTSP) for which the intermediary is an active party of. 

The rule engine module (102) parses through all or part of 
the data packets that passes through the intermediate network 
element and matches these data packets to a set of criteria 
specified by a singular or plurality of rules. This is known as 
evaluation of rules. These rules are specified in a logical unit 
known as a Rule Specification. A Rule Specification can 
contain a singular or plural number of rules. When a match is 
found, the corresponding action(s) specified in the rules is(are) 
triggered. This is known as the "firing of a rule". The action 
25 performed can include, but not limited to, inserting contents to 
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the data packets, removing part or all of the contents from the 
data packets, and modifying contents in the data packets. 
These insertion, removal, and modification of packets contents 
can be carried out on the intermediary, or some other remote 
5 machines dedicated to perform packets transformations. 

Examples of rules that are parsed by the Rule Engine 
(102) include rule which determines the bandwidth to be 
allocated to the data stream that the client is requesting. For 
instance, a rule may be specified in the following high-level 
10 form: 

"If network channel of client < = 1 Mbps, then allocate 10 kbits 
for data stream". (Rule 1) 

The rule engine module (102) implements the functionality 
to parse such rules and determines if a match (i.e. if the end- 

15 user's network channel has a capacity is less than or equals to 
1 Mbps) occurs. The above example also shows how the rules 
control the network resource allocation decisions. 

Another example of rules being parsed by the rule engine 
module (102) will be to determine the next intermediary or 

20 server to contact in response to a client's request received 
from the gateway module (101). Here, base on the parameters 
of the request, the request may be routed to a different 
server/intermediary. For instance, consider the following high- 
level rules: 

25 "If requested data is audio only, route request to foo3.bar.com" 
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(Rule 2a) 

"If requested data is audio and video, route request to 
foo4.bar.com" (Rule 2b) 

The rule engine module (102) is responsible in parsing 

5 and interpreting such rules, and determining if one of condition 
is met. When one is met, the rule engine module (102) will 
inform the gateway module (101) which next intermediary/server 
is selected, and the gateway module (101), which implements 
the actual functionality to communicate with others using the 

10 specific protocol, would proceed to route the request to the 
selected next intermediary/server. 

The intermediary in the current invention can have zero, 
single or plural number of special packages (103). These 
special packages (103) are modules designed to enhance the 

15 rule engine module (102) by providing specialized 
functionalities. For example, a Quality-of-Service (QoS) 
special package can be employed to assist the rule engine 
module (102) in understanding and evaluating rules that 
involves QoS parameters and conditions. The rule engine 

20 module (102) on its own can only parse rules and try to find a 
match on the conditions spelt out by the rule specifications. 
Using the example of (Rule 1a) above, the rule engine module 
(102) will need help to determine the actual capacity of the 
network channel of the client. A special package (103) for 

25 evaluating QoS parameters can be installed in the intermediary 
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to evaluate such expression. The rule engine module (102) 
would query the QoS special package (103) when it parses a 
rule specification that specifies a QoS parameter (such as 
bandwidth, delay, etc). The QoS special package (103) 
evaluates the value of the parameter in question and passed it 
back to the rule engine module (102). From there, the rule 
engine module (102) can then proceed to check if a match has 
occurred in the condition specified by the rule specification. In 
this way, a modular design of the intermediary can be achieved. 
The rule engine module (102) performs the job of parsing rule 
specifications. It utilizes different special packages (103) to 
evaluate the value of a parameter that is specified in a rule 
specification, and from the values, determines if a condition is 
matched. In the current invention, a special package for 
15 evaluating rules based on delivery context is set forth. 

The rule injection module (104) is a module that 
dynamically loads and unloads rules to and from the rule engine 
module (102). It also provides the interface for remote parties 
to dynamically register, activate or de-activate rules. This 
module is indispensable in supporting distribution of rules 
through various intermediaries. 

initially, when the intermediary starts up, the rule 
injection module (104) will load an initial set of rule 
specifications, based on a configuration file or otherwise, from 
25 the storage of the intermediary. The rules specifications will 
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be loaded to the rule engine module (102). When a client 
request (or server response data) arrives, the gateway module 
will processing the clients request (or server response data), 
and pass it to the rule engine module (102) for rule parsing. 
The rule engine module (103) will parse the rule specifications 
and try to seek for a match in the conditions specified against 
the request (or response). While parsing these rules, the rule 
engine module (102) may require assistant from special 
packages (103) to evaluate the value of parameters. 
3 The rule injection module (104) also allows rules to be 

dynamically loaded to the intermediary. For example, an 
administrator may remotely transfer a new set of rule 
specifications to be installed on the intermediary. Alternatively, 
the administrator may want to remotely remove a rule 
5 specification from the intermediary. The rule injection module 
(104) handles such remote operations. In addition, these 
operations need not be limited to human administrators. Indeed, 
the first portion of the current invention details the mechanism 
that allows rule specifications to be loaded and unloaded 
20 dynamically between intermediaries. The rule injection module 
(104) plays the role here of accepting connections from other 
intermediaries and handle requests to load or unload a rule 
specification to/from the rule engine module (102). 

Distribution of rules implies that rule specification(s) that 
25 is(are) loaded on one intermediary can be passed to another 
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intermediary to be evaluated. Whole or part of the rule 
specification may be indicated to be distributed. These 
indications also suggested to which intermediary along the data 
flow path to distribute to. Fig. 2 shows a typical content flow 
5 path. Note that there may be other network elements 
performing relaying task along the content path that are not 
shown in Fig. 2. Along the path from the content server (201) 
to the content user (207), there may be a single or plural 
number of intermediaries (202 - 206) with the current invention 

10 employed. 

Authors of the rule specification can indicate which 
intermediary along the content flow path to distribute the rule 
specification partially or wholly. Since it is unreasonable for 
authors to know how intermediaries are deployed in an actual 
15 real world situation, authors specify the preferred intermediary 
where the rule is distributed to by indicating the direction of the 
distribution, i.e. towards the source node or towards the 
destination node. The term -source" and "destination" are used 
with respect to the data packets. The source node is the node 
that generates the data packet, and the destination node is the 
node that consumes the data packet. In a server-client model, 
the directions may be specified as "towards server" or "towards 
client". 

For example, using the deployment scenario as illustrated 
25 in Fig. 2, a rule specification is submitted to the intermediate 
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network element foo4.bar.com (204). A part of the rule is 
indicated to be distributed towards the "destination". When 
processing a request packet, i.e. packet sent from the content 
user (207) to the content server (201), this portion of the rule 
5 specification can be distributed to the intermediary 
foo2.bar.com (202) or the Intermediary foo3.bar.com (203). 
Conversely, when processing a response packet, the same 
portion of the rule specification can be distributed to the 
intermediate network element foo6.bar.com (206) or the network 
10 element foo5.bar.com (205). Similarly, when a part of the rule 
is indicated to be distributed towards the "server", it can be 
distributed to the intermediary foo2.bar.com (202) or the 
intermediary foo3.bar.com (203). Conversely, when a portion of 
the rule specification is indicated to be distributed towards the 
15 "client", that portion of the rule specification can be distributed 
to the intermediate network element foo6.bar.com (206) or the 
network element foo5.bar.com (205). 

One objective of the current invention is to allow rule 
authors to be able to specify a rule hierarchy where the 
20 topmost level of the rule specification resides on one 
intermediary and the lower level portions of the rule 
specification reside on other intermediaries. This allows 
efficient control of the intermediary operations. Thus, in 
addition to specifying the direction at which distributed rules 
25 should flow (i.e. forward, backward, towards content server or 
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towards content user), the current invention also allows rule 
authors to specify the approximate location in that direction 
where the rule should be distributed. 

Using the above example, a rule author may specify the 
distributed portion of the rule specification to be distributed to 
the intermediary as near to the content user as possible. In Fig. 
2, this implies the intermediary foo6.bar.com (206). 
Alternatively, a portion of the rule might be specified to be 
distributed to the intermediary one hop away from the element 
nearest to the content user. In Fig. 2, this implies the 
intermediate network element foo5.bar.com (205). Similarly, it 
is possible for the rule author to specify that a portion of the 
rule to be distributed to the next intermediary towards the 
content server. Using the previous example where the rule 
15 specification is submitted to foo4.bar.com (204), this means the 
rule author wanted the portion of the rule to be distributed to 
the network element foo3.bar.com (203). 

The current invention covers all the afore-mentioned 
means of marking the rule specification for distribution. As an 
illustration, the following character-based indication methods 
are presented. It should be apparent to anyone skilled in the 
art that other forms of indications can be used to achieve equal 
effect, such as using numeric or alphanumeric codes. In the 
character-based indications, each indications is of the form 
25 <target direction>-<approximate location from target> 
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or of the form 

opproximate location towards target>-<target direction> 
where <target-direction> is the term source, destination, server 
or client, and opproximate location from target> and 
5 opproximate location towards target> are numerical values 
indicating the number of intermediaries away from the specified 
target. 

For instance, to indicate the portion of rule to be 
distributed to the intermediary nearest to the content server, 

10 the rule author may use an indication of server-1 to show that 
the rule should be distributed to the intermediary that is 1 hop 
away from the content server. When the indication of 2-server 
is used, the rule author expressed the desire to distribute the 
rule to an intermediary that is 2 hops away from the 

15 intermediary where the rule is loaded, towards the direction of 
the content server. Similarly, the indication client-2 indicates 
the rule should be distributed to the intermediate network 
element that is 2 hops away from the content user, and the 
indication 1-client indicates that the rule should be distributed 

20 to the next intermediary in the direction of the content user. 

In order for intermediaries to distribute rule specifications 
among themselves, the intermediaries must have a way to first 
discover the existence of other intermediaries on a given 
content flow path. Each intermediary may also be connected to 

25 multiple content servers, content users and other intermediaries, 
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thus discovery may not be feasible to be performed statically 
using configuration files, nor one-shot at system starts up. 

The present invention requires that intermediary to embed 
an indication of their presence in the content as data packets 
flows from the content user to the content server and vice versa. 
Such an indication is known as the signature of the 
intermediary. These signatures should contain information of 
the intermediary, such as the resolvable hostname and the 
capabilities of the intermediary. Capability of the 

intermediaries should clearly indicate that the intermediary 
support distributed rules, and should also include information 
such as the special packages installed in the intermediary. 

For example, in the HTTP and RTSP protocols, 
intermediaries can append their signature to the "Via" general 
header found in the request and response headers. An 
intermediary of hostname foo4.bar.com with installed QoS 
special package can insert the following "Via" header field as 
its signature: 

Via: 1.1 foo4.bar.com (OPES = standard,qos.distributed) 
20 For other protocols which do not have built-in mechanism 

for intermediaries to embed their signature, other means could 
be sought for. For instance, protocols usually provide the 
functionality for machines to embed optional information into 
the data packets (normally using optional extension headers). 
This can be used to carry signatures of the intermediary. In 
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addition, the above example used character strings as the 
signature for ease of understanding. It should be apparent to 
anyone skilled in the art that other forms of signature can be 
used to achieve equal effect, such as using numeric or 
5 alphanumeric codes, so long as an external entity can extract 
the hostname and capabilities of the intermediary from the 
signature. 

,n both cases where the protocol built-in mechanism is 
used, or optional extension is used, multiple signatures should 
10 be allowed so that signature of each subsequent intermediary 
can be appended. In other words, when a data packet reach 
any given intermediate network element in the content flow path, 
the intermediate network element knows the other 
intermediaries the data packet has previously traversed. This 
also enables the intermediary to know the order of the 
intermediaries the packet traversed. 

in a typical operation, there will be request flowing from 
the content user to the content server, and the response 
flcwing from the content server to the content user. 
Intermediaries will thus know all other intermediaries along the 
content flow path once a pair of request and response data 
packets passed through them. For instance, using the scenario 
shown in Fig. 2. the intermediary foo4.bar.com (204) will know 
the existence of the intermediaries foo6.bar.com (206) and 
25 foo5.bar.com (205) when the request from the content user 
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(207) reaches it. When the content response from the content 
server reaches foo4.bar.com (204), the intermediary will 
discover the existence of the intermediate network elements 
foo2.bar.com (202) and foo3.bar.com (203). Thus, the 

5 intermediary foo4.bar.com (204) will be able to detect the 
presence of other intermediate network elements in the entire 
content flow path. 

Intermediaries will maintain a cache of known 
intermediaries network along any given content flow path. The 

10 reason for doing so is explained below. When an intermediary 
received a request, it may be necessary for it to distribute a 
rule to another intermediate network element towards the 
content server. If the intermediary relies only on the embedded 
signature to discover other Intermediate network elements, it 

15 cannot know in advance other intermediaries in the forward 
path towards the content server, until it receives the content 
response. Should such a situation arise, the rule engine 
module (102) should check if it could retrieve information of 
intermediaries from its cache. If it can, then the rule can be 

20 distributed to a forward intermediary; else, the rule should be 
evaluated locally. 

To maintain the cache, the data formats as shown in Data 
Format 1 and Data Format 2 below can be used. Data Format 
1 is used to record the host identification (stored in the field 

25 hostname) and capabilities (stored in the field capabilities) of 
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the intermediary. Data Format 2 is used to record the list of 
known intermediaries along a given content flow path. The 
content flow path is uniquely specified by the source (stored in 
the field source), destination (stored in the field destination). 
5 and protocol (stored in the field protocol) triplet, expressed as 
(source, destination, protocol}. The num_nodes field store the 
number of intermediate network element that a data packet from 
the source node must traverse before reaching the destination 
node starting from (but excluding) the current intermediary, and 
10 the nodes array store the information of each of such 
intermediate network element. Fig. 3 illustrates a pair of 
ContentPath data formats stored in the intermediary 
foo4.bar.com (204) in the scenario depicted Fig. 2. 

15 struct IntermediaryEntry { 

NodelD hostname; 
char capabilities']; 

} 

20 Qala Forma t V In^rmarliarv Entry 



25 



struct ContentPath { 

NodelD source; 
NodelD destination; 



WO 03/078459 




T/JP03/03140 



23 



ProtocolType protocol; 
int num_nodes; 
struct IntermediaryEntry nodes[]; 

> 

5 

nata Format ?• Data Flow Path Information 



Fig. 4 depicts the method devised to extract the 

10 intermediaries' signatures embedded in the data packets and 
construct/update the ContentPath structure. When a data 
packet arrives, the intermediary first check if there is any 
signature embedded, as shown in the step marked with literal 
401. If there is one, a ContentPath structure is searched from 

15 the cache that matches the {destination, source, protocol) 
triplet, as shown in step marked with literal 402. Note that the 
source of the data packet is checked for against 
ContentPath. destination, and vice versa. The reason for this is 
because the ContentPath structure is used to give the list of 

20 intermediaries towards the destination node, whereas when 
extracting signatures from the data packets, the intermediaries 
are given from the source node. Thus, there is a need to swap 
the destination and source nodes when searching for a match. 

If none can be found, a new ContentPath structure is 

25 allocated, as shown in step marked with literal 403. When a 
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cached ContentPath structure is located, the num_nodes and 
nodes fields will be purged, as shown in the step marked with 
literal 404. A last-in-first-out stack to store the signatures 
temporarily is then initialised to be empty and the counter n is 

5 set to zero in the step marked with literal 405. In the step 
marked with literal 406, each embedded signature is extracted 
and pushed to the stack. In addition, the counter n is 
incremented to record the number of signatures extracted. 
When all signatures are extracted, the counter n will contain 

10 the number of intermediaries before the current network 
element in the content flow path. This is stored to the 
num_nodes field. Signatures in the stack are then popped out 
to update the nodes array, as shown in the step marked with 
literal 406. 

15 Previous description has presented the method for 

intermediaries to discover other intermediaries along the 
content flow path. When a rule engine module parses a rule 
specification and found that a portion of the rule specification 
is marked to be distributed, it can then check the appropriate 

20 ContentPath structure (by using the content server, content 
user, and protocol triplet) and determine which remote 
intermediaries to distribute the rule to. 

Fig. 5 shows the algorithm used to determine the remote 
intermediary to distribute the rule to, given the indication of 

25 distribution in the form of 
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<target direction>-<approximate location from target> 



or 



approximate location towards target>-<target direction> 
as previously described. The term target is used to denote the 
5 numerical value of approximate location towards target> or 
approximate location from targets The term directive 
contains the value "from" if the first form is used, and the value 
-to" if the second form is used. The term direction is the value 
-source- or the value "destination". The term src, dst and 
10 protocol refers to the source, destination and protocol extracted 
from the data packet respectively. 

The algorithm first searches for the ContentPath data 
format as shown in the steps marked with 501 through 504. If 
the direction of distribution is towards the destination, the 
15 triplet {src, dst protocol} is used to locate the ContentPath, as 
shown in the step marked with literal 502. Else, the triplet {dst, 
src, protocol} is used instead, as shown in the step marked with 
literal 503. If no ContentPath can be found, the algorithm 
returns NULL, as shown in the step marked with literal 512. In 
20 the steps marked with 505 and 506, target in checked to 
prevent it from exceeding the number of remote intermediaries 
in the direction of distribution. In the step marked with literal 
507, the distribution indication is checked to see if it is in the 
form 

25 <target direction>-<approximate location from target> 
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approximate location towards target>-<target direction> 

For the first form, the numerical value indicates the 
number of intermediary from the end host (content server or 
content user). However, the intermediaries are listed in nodes 
array in the order of the direction towards the end node. Thus, 
in the step marked with literal 508, a temporary variable x is 
set to the number of intermediaries minus the numerical value 
target. Conversely, if the indication is in the second form, then 
the temporary variable x is set to the numerical value target 
minus 1. as shown in the step marked with literal 509. The 
reason to subtract one is because the first element in the nodes 
array is assumed to be nodes t 0]. Anyone skilled in the art can 
easily modify the above formulae to suit other kinds of array 
arrangement. In the step marked with literal 510, the variable x 
is checked to see if falls out of range. If it does, the algorithm 
returns NULL to indicate no suitable remote intermediary can 
be found, as shown in the steps marked with literal 512. Else, 
the function returns the remote intermediary given in nodesM, 
as shown in the step marked with literal 511. 

Fig. 6 shows the method of parsing a rule specification 
with the consideration of distributing rules. The rule 
specification is first parsed to check for syntactical validity, 
and invalid rules are rejected, as shown in the steps marked 
with 601, 602, and 603. The rule Is next checked to see if the 
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it is marked to be distributed, as shown in step marked with 
Uteral 604. If it is not marked, the rule is evaluated locally 
(605). Else, the algorithm depicted in Fig. 4 is used to identify 
the remote Intermediary to distribute the rule to, as shown in 
the step marked with literal 606. If the algorithm returns NULL, 
that means no suitable remote intermediary can be found, then 
the rule is evaluated locally, as shown in steps marked with 607 
and 605. When a remote intermediary is found, it is checked to 
see if it supports the special package required by the rule, as 
shown in step marked with literal 608. If it does not, the rule is 
evaluated locally (605). If it does, the rule is then distributed 
(609). The whole process is repeated for the next rule to be 
parsed (610). 

If a server-client model is used, where the target direction 
15 can be specified by towards "server" or towards "client" instead, 
then the method of locating the target intermediary given in Fig. 
5 can no longer be used. Fig. 7 shows the method for a server- 
client model. The only difference between the algorithm in Fig. 
7 and the one in Fig. 5 is in the steps marked with literals 701 
20 through 703, and the steps marked with literals 501 through 503. 
in the step marked with literal 701, the target direction is first 
checked if it is towards server or client. If the target direction 
is server, the ContentPath is searched using the { node 
identification of client, node identification of server, protocol } 
25 triplet, as shown in the step marked with literal 702. If the 
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target direction is client, the ContentPath is searched using the 
{ node identification of server, node identification of client, 
protocol } triplet, as shown in the step marked with literal 703. 
The remaining steps marked with literals 704 through 712 are 

5 identical to the steps marked with literal 504 through 512. 

In order to distribute the rule, the intermediary needs to 
signal the receiving intermediary. For ease of explanation, the 
scenario that is illustrated in Fig. 2 is used. For the following 
discussion, the intermediary foo4.bar.com (204) is the network 

10 element that loads the rule, and it has determined that the rule 
needs to be distributed to the Intermediary foo6.bar.com (206) 
for evaluation. 

To signal foo6.bar.com (206), foo4.bar.com (204) can 
embed a signal into the data packet. The present invention 

15 requires that the embedded signal contain the identifier of the 
intermediary that is distributing the rule, the identifier of the 
intended intermediary receiving the rule, and the rule identifier 
that uniquely identifies the rule to be distributed. The rule 
identifier must uniquely identify the portion of the rule 

20 specification on a given intermediary that is to be distributed, 
and the identifier should not vary with time. 

For example, in the HTTP and RTSP protocols, 
intermediaries can append tokens to the "Pragma" general 
header in the request and response headers. Thus, the current 

25 invention can make use of this to embed the required signals. 
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For example, foo4.bar.com can append the following token 
OPES-distributed=»foo6.bar.com:XYZABC@foo4. bar.com"; 

to the "Pragma- general header of the response. The token 

used is of the form 
5 oPES-dlstributed=«<target>:<ru.eidentifier>@<distributor>- 

where <target> refers the hostname of the intermediary to 
receive the distributed rule. <rule identified refers to the 
unique identifier to identify the distributed rule, and 
<distributor> refers to the intermediary that is distributing the 
10 rule. 

For other protocols which do not have built-in mechanism 
for intermediaries to embed signals, other means could be 
sought for. For instance, protocols usually provide the 
functionality for machines to embed optional information into 
the data packets (normally using optional extension headers). 
This can be used to carry signals for intermediary. In addition, 
the above example used character strings as the signature for 
ease of understanding. It should be apparent to anyone skilled 
in the art that other forms of signature can be used to achieve 
equal effect, such as using numeric or alphanumeric codes, so 
long as an external entity can extract the hostname of the 
distributing intermediaries, hostname of the target intermediary 
and the rule identifier from the signal. 

In both cases where the protocol built-in mechanism is 
used, or optional extension is used, multiple signals should be 
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allowed so that two or more sets of rules can be distributed at a 
single passing of a data packet. Every intermediary must 
inspect the data packets to detect such signals, and check if 
the signal is intended for it. Once it determined the signal is 
intended for it, the intermediary can optionally remove the 
signal from the data packet. 

The rule identifier is used to retrieve the actual rule from 
the distributing intermediary using a separate communications 
channel. The rule injection module (104) is responsible for 
establishing such a communications channel and 
retrieving/passing any distributed rule. The current invention 
does not specify the format of such a communications channel. 
Because the rule identifier is unique given a specified 
intermediary, intermediaries shou.d cache the retrieved 
distributed rule using the rule identifier and the hostname of 
the distributing intermediary as a cache key. This eliminates 
the need to retrieve the same distributed rule should a 
subsequent distribution occur again. 

The above mechanisms can be deployed for contents 
distribution where there is a plurality of sending and receiving 
nodes. Such situation is decomposed into multiple data flow 
paths, each containing one sending node and one receiving 
node. Note that this decomposition is only used for the 
construction of the ContentPath structure as described 
previous.y. When an actual data that arrives at an intermediary 
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that is sent to plurality of receiving nodes, the intermediary can 
then decide on the rule distribution based on each ContentPath 
structure for each corresponding sending node (i.e. source) and 
receiving node (i.e. destination) pair. If the targeted 
5 intermediary to distribute a rule to happens to be the same, 
then a single signal can be embedded onto the content. If more 
than one target intermediary is identified (because the content 
path split somewhere along the line), one separate signal for 
each targeted intermediary can be embedded into the content. 
-jO In the previous descriptions, the intermediate network for 

distribution of rule is revealed. This document will, in the 
following discussions, turn to the next portion of the current 
invention, which narrows the deployment of the current 
invention to real time content streaming situation. In this 
15 situation, the content user sends a request to the content 
server, via a single or plural number of 
intermediary(lntermediaries) which is(are) the object(s) of the 
current invention, to set up a real time session. When the 
content server accepts the request with an appropriate 
20 response, a communications channel is set up between the 
content server and the content user through the 
intermediary(intermediaries). This communications channel 
between the content server and content user is hereafter 
referred to as the content session. The content server starts 
25 transmitting data packets through the content session to the 
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content user without any active request from the content user, 
until the content user sends a request, via the intermediary, to 
tear down the content session. Such data packets sent 
spontaneously by the content server are henceforth referred to 
5 as content packets. During the course of the transmission of 
content packets by the content server, the content user may or 
may not transmit information about the transmission statistics 
back to the content server. Such statistics are hereafter 
referred to as feedback packets. 
10 One existing protocol that fits the above description is the 

Real Time Streaming Protocol (RTSP). However, the current 
invention can be applied to other protocols that exhibit the 
same behaviour previously described, as should be apparent to 
anyone skilled in the art. 
15 For all known prior arts, rules are evaluated for each 

request and/or response packets that passes through the 
intermediary. The current invention extends this by providing 
the capability for rule authors to specify rules that are 
evaluated whenever a content packet passes through the 
20 intermediary, rules that are evaluated whenever a specifies 
multiple of content packets passes through the intermediary, 
rules that are evaluated when a feedback packet passes 
through the intermediary, and rules that are evaluated at a 
specified regular interval throughout the duration when the 
25 content session is established. To attain such provision, rule 
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authors are allowed to tag each rule with a special attribute. 
For purpose of explanation, the attribute is referred to as the 
"evaluateOn" attribute. Table 1 below listed the possible 
values of the "evaluateOn" attributes. Anyone skilled in the art 
should recognized that the current invention can be deployed 
using other names. 
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"evaluateOn" 
Attribute 


Description 


"request" 


the rule is to be evaluated upon the reception 
by the intermediary of a request packet from 
th* r.ontent user to the content server 


"response" 


the rule is to be evaluated upon the reception 
by the intermediary of a response packet from 
th« r.ontent server to the content user 


"content" 


the rule is to be evaluated upon the reception 
by the intermediary of a content packet from 
the content server to the content user 


"feedback" 


the rule is to be evaluated upon the reception 

L *u« intnrmorfiarv of a feedback packet from 
by the intermeuiary 01 a iccuuuvn r 

+ h« content user to the content server 


"x-contents" 


the rule is to be evaluated upon the reception 
by the intermediary of x multiple number of 
content packets from the content server to the 
content user, where x is a specified numerical 
value — 7 r~ 


"t-seconds" 


the rule is to be evaluated when a content 
packet is received upon elapsed of every 
seconds interval for as long as the content 
session is established, where t is a specified 
| numerical value . i 



T> h |ft -i- » oygi<m*ftOn" Attributes 
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The last part of the current invention concerns the 
employment of special packages (103). As described earlier, 
special packages (103) are modules that enable the rule engine 
module (102) to evaluate rules involving different set of 
parameters (such as Quality of Service). The current invention 
defines a new special package, known as the "De.ivery Context- 
special package. This package will allow the rule engine 
module (102) to interpret rules that are constructed based on 
delivery context. Four major classes of delivery context are 



WO 03/078459 



T/JP03/03140 



35 



10 



15 



defined, as shown in Table 2 below. These are User 
Preferences, Agent Capabilities, Device Capabilities, and 
Natural Environment. User Preferences refers to information 
about the human user, including browsing preference, language 
preferences, display preferences, QoS preferences, age group 
and gender. Agent Capabilities provide information on the 
software agent, such as the agent type, supported formats, 
supported languages, and supported transport protocols. 
Device Capabilities refers to the information about the 
hardware device, which include the device type, processor 
speed and type, memory capacity, screen resolution and depth, 
and operating systems. Natural Environment provide 
information about the natural environment surrounding the end 
user, including whether the end user is indoor or outdoor, the 
end user's velocity, location of the end user, and illumination 
properties. 
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User Preferences 1 


Parameters 
"browsing- 
preference" 


Values m . , 1 

descriptive text about the user's browsing I 
preferences, such as text only, image sizes, 
handicaps accessibilities options, searching 1 
and filtering preferences — 1 


"language- 
preference" 


descriptive text about user's order of language 1 
preferences ___ 1 


"display- 
preference" 


descriptive text about user's color preferences, 
full screen or window I 


"ape-group" 
"qender" 


descriptive text about the user's age group | 
descriptive text about the user's gender 


"employment I aescripuve xexi auuui.me uo^i ^ ,i~^, r . 

Aaent Capabilities _J 


Parameters 


Values . J 


"agent-type" 


descriptive text about the software aaent 


"supported- 
formats" 


descriptive text about the content formats 1 
supported, and content encoding supports 1 


"supported- 
languaaes" 


descriptive text about the language supported | 
bv the software agent — 1 


"supported- 
protocols" 


descriptive text about the transmission | 
protocols supported by the software agent, and 1 
whether it has multicasting, broadcasting I 
capabilities } 


Device Capabilities 1 


Parameters 


Values t 1 


"device-type" 


descriptive text about the device type 1 


"processor" 


descriptive text about processor speed and 1 
family — — — — I 


"memory- 
capacity" 


descriptive text about memory capacity ot tne i 
physical and secondary memory I 


"screen" 

"operating- 

svstem" 


descriptive text about resolution and depth J 
descriptive text about the operating system 1 
tvoe _ — 1 


^ Natural Environment 1 


Parameters 


Values . 1 


"location" 


descriptive text about the user's location, such j 
as indoor or outdoor, and the locale I 


"mobility" 


descriptive text about the user's mobility, | 
whether fixed or moving, and the velocity if 
moving . — 


"illuminations" 


descriptive text about illuminations surrounding 
the end user 1 



Table 9: p g ljvery pnntayt Parameters 
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The Delivery Context special package Interprets rules that 
are constructed using parameters that are from delivery context. 
There are various methods where the delivery context special 
package can obtain the actual values of the parameters. One 
method is to establish a communications channel with an 
external entity that provides knowledge of such parameters, for 
example the content user. For parameters such as the Device 
Capabilities, it might be necessary to obtain it from the content 
user directly. An alternative method is to obtain it from another 
module that resides on the intermediary. This module may 
gather the values locally, load the values from a storage device 
or request the values from an external entity. For parameters 
such as the Natural Environment, the intermediary may be able 
to deduce the information on its own, especially when the 
15 intermediary is located near the content user. For parameters 
such as the User Preferences, the human user may have 
registered a set of profiles to be stored at the intermediary. 

The invention allows intermediate network elements along 
a content flow path to actively collaborate their content delivery 
efforts to enhance user experience in content retrieval. With 
more and more content delivery networks (CDN) deployed in the 
internet, the Invention disclosed in this document allows 
intermediaries of such CDNs to orchestrate their efforts by the 
provision of distributed rules. Rules loaded on one network 
25 element can be distributed to other intermediaries in real time, 
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so that adaptation of data contents and contents request can be 
performed at a more suitable node. It also allows better control 
over the operations of content delivery. 

In addition, the disclosed invention contains methods and 
means which are specific to the real-time delivery of Audio 
Visual content in a packet switch network. This allows rule 
authors to create rules that can react to fluctuations in the 
network conditions of the content streaming more speedily. 
Authors can also create rules that are based on the device 
capabilities and user preferences of the content consumers. 
When such rules are authored carefully with suitable adaptation 
services, the overall user experience in content retrieval will be 
significantly enhanced. 
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1. A network control framework apparatus for controlling 
resources at an intermediate network element connecting two or 

5 more communications networks comprising of the following 
entities: 

«. the gateway module providing gateway functionality, 

ii. the rule engine module to perform network resource 

control decision based on specified rules, wherein the 
10 rules are specified in a rule specification format 

hereafter known as a Rule Specification, 

iii. a single or plural number of special package add on to the 

rule engine module where a said special package offers 
specialized functionality to the rule engine module, and 
15 iv.the rule injection module to inject or remove Rule 

Specification to or from the rule engine module. 

2. A means for distribution of Rule Specification as recited 
in claim 1 to a single or plural number of intermediate network 

20 elements as recited in claim 1, comprises of 

i. the indications in the Rule Specification to indicates part 

or whole of the Rule Specification is to be distributed, 

ii. the signature embedded into data packets to announce the 

capabilities of the intermediate network elements the 
25 data packet traversed, 
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iii. the method of parsing the Rule Specification to determine 

if part or whole of the specified Rule Specification is 
distributed, 

iv. the method of identifying the target network element to 

distribute part or whole of a Rule Specification, 

v. the signaling embedded into data packets to inform target 

network element of the distribution of part or whole of 
Rule Specification, 

vi. the retrieval of the part or whole of Rule Specification 

distributed to the target network element from, the 
intermediate network element that distributes the part 
or whole of Rule Specification. 



3. 



A format of indications of part or whole of Rule 
15 Specification for distribution as recited in claim 2 to a single or. 
plural number of intermediate network element as recited in 

claim 1, comprises of 

i. the specification of the direction of distribution by 

specifying the endpoint of the specified direction, 

ii. the specification of the number of intermediate network 

elements towards the specified endpoint, 

iii. the specification of the number of intermediate network 

elements from the specified endpoint, and/or 

iv. the specific content distributed at the intermediate 
25 network elements. 
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4. A format of signature embedded into single or plural 
number of data packets as recited in claim 2 to announce the 
capabilities of the intermediate network elements as recited in 
5 claim 1 the data packets traversed, comprises of 

the identification of the intermediate network element the 
signature belongs to, 

ii. the special packages as recited in claim 1 that are 

installed on the intermediate network element the 
10 signature belongs to, and 

iii. the capability of accepting or generating part or whole of 

a Rule Specifications for distribution. 

5. A means for intermediate network elements as recited in 
15 claim 1 to store the signatures embedded in single or plural 
number of data packets as recited in claim 2 or 4 wherein the 
signatures of the intermediate network elements that the data 
packets traversed are stored with the starting and ending points 
between which the data packets traversed in the order of which 
20 the data packets traversed and the transmission protocol the 
data packets belongs to. 

6. The data format used to store the signature of 
intermediate network element as recited in claim 1. 2, 4 or 5, 
25 containing the identification of the intermediate network 
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element and the installed special packages as recited in claim 
1 at the intermediate network element. 

7. The data format used to store the signatures of the 
5 intermediate network elements as recited in claim 1, 2, 4, or 5 
that a single or plural number of data packets flowing from one 
endpoint to another traverses, containing 

i. the identification of the ending point that the data packets 
flow to, 

10 ii. the identification of the starting point that the data 

packets flow from, 
hi. the transmission protocol the data packets belongs to, 

iv. the array of signatures of the intermediate network 

elements in the order of the data packets traverse from 
15 the intermediate network element where the data format 

is stored to the ending point, and 

v. the number of signatures of the intermediate network 

elements in the order of the data packets traverse from 
the intermediate network element where the data format 
20 is stored to the ending point. 

8. A method of extracting the signature of intermediate 
network elements embedded in single or plural number of data 
packets as recited in claim 1. 2, 4 or 5, to be stored in the data 
25 format as recited in claim7, comprises the steps of 
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i. checking if there are embedded signatures in the data 
packets, 

ii. checking if there exist a data format as recited in claim 7 
that is previously stored having the same starting and 
ending points and transmission protocol, 

reallocating a new data format when there is no data format 
that is previously stored having the same starting and 
ending points and transmission protocol, 

iv. purging data stored in the data format that previously 
existed having the same starting point, ending point 

and transmission protocol, 

v. preparing an empty last-in-first-out data structure, 

vi. extracting each embedded signature in the data packet 

and pushing it to the last-in-first-out data structure, 
15 V ii. removing each element in the last-in-first-out data 

structure and recording it to the data format as recited 
in claim 7, and 

viii. recording the number of embedded signature extracted 
in the data format recited in claim 7. 



10 



20 



9. A method of parsing the Rule Specification as recited in 
claim 2 to determine if part or whole of the Rule Specification 
is to be distributed comprises the steps of 

i. checking each rule in the Rule Specification for 
25 syntactical validity, 
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ii. rejecting the rule if there is syntactical errors, 

iii. checking the rule for the distribution indication as recited 

in claim 3, 

devaluating the rule locally if there exist no distribution 

5 indication, 

v. determining the remote intermediate network element to 

distribute the rule to, 

vi. evaluating the rule locally if no suitable remote 

intermediate network element to distribute the rule to 

10 can be found, 

vii. checking if the remote intermediate network element 
contains the special package or special packages 
required in the rule, 

vlll. evaluating the rule locally if the remote intermediate 
15 network element do not have the required special 

package or special packages, and 
ix.distributing the rule to the remote intermediate network 
element. 



20 



25 



10. A method of determining the remote intermediate network 
element that a rule is to be distributed to as recited in claim 9, 
given the distribution indication as recited in claim 3, 

comprises the steps of 

i. the method of locating the data format as recited in claim 
7 with the matching starting point, ending point and 
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transmission protocol, 

ii. declaring no suitable remote intermediate network element 

if no data format as recited in claim 7 can be located, 

iii. setting the a temporary variable to the specified number 

of the intermediaries towards or from the specified 
endpoint in the given distribution indication, 

iv. setting the temporary variable to the value of the number 

of intermediaries as given in the located data format as 
recited in claim 7 if the specified number of the 
intermediaries towards or from the specified endpoint in 
the given distribution indication is greater than the 
number of intermediaries towards or from the specified 
ending point in the given distribution indication, 
v. whereas the specified distribution indication as recited in 
claim 3 consists of the specification of the ending point 
and the specification of the number of intermediate 
network elements towards the specified ending point, 
set the temporary variable to a value equals the number 
of intermediaries given in the located data format as 
recited in claim 1 minus the original value in the 
temporary variable, 
vi . whereas the specified distribution indication as recited in 
claim 3 consists of the specification of the ending point 
and the specification of the number of intermediate 
network elements from the specified ending point, set 
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the temporary variable to a value equals the original 
value in the temporary variable minus 1, 
vii. declaring the remote intermediate network element to 
be the network element specified in a signature stored I 
5 the located data format as recited in claim 7 where the 

signature has an index in the array of signatures in the 
located data format as recited in claim 7 equals to the 
value stored in the temporary variable should such an 
index exits, and 

10 viii. declaring no suitable remote intermediate network 

element should the index equal to the value stored in 
the temporary variable does not exist in the array of 
signatures in the located data format as recited in 
claim 7. 

15 

11. A format of signalling to signal the intermediate network 
element as recited in claim 1 to express the desire to distribute 
collection of a single or plural number of rules in a Rule 
Specification to the intermediate network element consisting of 
20 i. the identification of the intermediate network element 

where the collection of single or plural number of rules 
in a Rule Specification is distributed to, 
ii. the identification of the intermediate network element 
where the collection of single or plural number of rules 
25 in a Rule Specification is distributed from, and 
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Hi. the Identification of the collection of single or plural 
number of rules in a Rule Specification. 

12. A means of retrieving the collection of single or plural 
5 number of rules in a Rule Specifcation from the intermediate 
network element as recited in claim 1 that distributes the 
collection of rules by the intermediate network element where 
the collection of rules is distributed to. comprises of 

i. the establishment of a communication channel between 
10 th e intermediate network element where the collection 

of rules is distributed to and the intermediate network 
element where the collection of rules is distributed from, 

ii. the provision of the identification of the collection of rules 

that is distributed as recited in claim 11 via the 
15 communications channel by the intermediate network 

element where the collection of rules is distributed to, 
and 

iii. the transmission of the collection of rules that is 

distributed via the communications channel by the 
20 intermediate network element where the collection of 

rules is distributed from. 

13. A network control framework apparatus for controlling 
resources at an intermediate network element connecting two or 
25 more communications networks, wherein an endpoint node 
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hereafter known as a client node sends a request to the other 
endpoint node hereafter known as a server node, via a single or 
plural number of the intermediaries, and the server node 
accepts the request with an appropriate response, and a 
communications channel is set up between the server content 
server and the client node through the intermediaries, and the 
server node starts transmitting data packets through the 
communications channel to the client node until the client node 
sends a request, via the intermediaries, to tear down the 
communications channel, and the client node may transmit 
information about the transmission statistics back to the server 
node, comprises of the following entities: 

i. the gateway module providing gateway functionality, 

ii. the rule engine module to perform network resource 
15 control decision based on specified rules, wherein the 

rules are specified in a rule specification format 
hereafter known as a Rule Specification, 
Hi. a single or plural number of special package add on to the 
rule engine module where a said special package offers 
20 specialized functionality to the rule engine module, and 

iv.the rule injection module to inject or remove Rule 
Specification to or from the rule engine module. 



25 



14. A means of providing the author of Rule Specification as 
recited in claim 13 to trigger a singular or plurality of rules at a 
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intermediate network element as recited in claim 13 based on 
the following control methods 

i. the rule to be evaluated when the intermediate network 

element received a request packet from the client node 
to the server node, 

ii. the rule to be evaluated when the intermediate network 

element received a response packet from the server 
node to the client node, 

iii. the rule to be evaluated when the intermediate network 

element received a data packet containing contents 
sent by the server node to the client node through the 
communications channel established between the 
server node and the client node, 

iv. the rule to be evaluated when the intermediate network 

element received a data packet containing the 
transmission statistics from the client node to the 
server node, 

v. the rule to be evaluated when the intermediate network 

element received a specified number of data packet 
containing contents sent by the server node to the 
client node through the communications channel 
established between the server node and the client 
node, and 

vi. the rule to be evaluated when the intermediate network 

element received a data packet containing contents 
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sent by the server node to the client node through the 
communications channel established between the 
server node and the client node after the elapse of a 
recurrent timer of a specified timer value. 

5 

15. A set of parameters used in the Rule Specification as 
recited in claim 1 to control a single or plural number of content 
or content delivery sessions to achieve device independence in 
the delivery of said content, consisting of 
10 i th e set of User Preference parameters consisting of the 

preferences of the human user consuming the content 
ii. the set of Agent Capabilities parameters consisting of the 
capabilities of the software agent employed by the 
human user to retrieve the content, 
15 Hi. the set of Device Capabilities parameters consisting of 

the capabilities of the hardware employed by the human 
user to retrieve the content, and 
iv.the set Natural Environment parameters consisting of the 
information about the environment in which the human 
20 user retrieves the content. 

16. The set of User Preference parameters as recited in claim 

15 consisting of 

i. the human user's preferences on the method of retrieving 

25 the content, 
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ii. the human user's preferences on the language used in the 

retrieved contents, 
Ui.the human user's preferences on the presentation of the 

retrieved content, 
5 iv.the age group of the human user retrieving the content, 

v. the gender of the human user retrieving the content, and 

vi. the employment status of the human user retrieving the 

content. 

10 17. The set of Agent Capabilities parameters as recited in 
claim 15 consisting of 

i. the type of software agent employed by the human user to 

retrieve the content, 

ii. the content formats supported by the software agent 
15 employed by the human user to retrieve the content, 

iii. the content languages supported by the software agent 

employed by the human user to retrieve the content, 
and 

iv. the transmission protocols supported by the software 
20 agent employed by the human user to retrieve the 

content. 



25 



18. The set of Device capabilities parameters as recited in 
claim 15 consisting of 

i. the type of hardware employed by the human user to 
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retrieve the content, 

ii. the processor speed and processor family of the hardware 

employed by the human user to retrieve the content, 

iii. the memory capacity of the physical and secondary 
5 storage of the hardware employed by the human user to 

retrieve the content, 

iv. the display depth and resolution of the hardware employed 

by the human user to retrieve the content, and 

v. the operating system running on the hardware employed 
10 by the human user to retrieve the content. 

19. The set of Natural Environment parameters as recited in 
claim 15 consisting of 

i. the information of the location where the human user is 
15 retrieving the content, 

ii. the information of the mobility of the human user 

retrieving the content, and 

iii. the information of the illuminations conditions in which the 

human user is retrieving the content. 

20 

20. The special packages installed to the intermediate 
network element as recited in claim 1 capable of interpreting 
and evaluating Rule Specification that are constructed using 
the sets of parameters as recited in claim 15, 16, 17, or 18. 



25 
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ContentPath = { 

source = "foo.user.com" 
destination = "foo.server.com" 
protocol = ... 
num_nodes = 2 
nodes[0] = { 

hostname = "foo3.bar.com" 

capabilities = ... 

} 

nodes[1] = { 

hostname = "foo2.bar.com" 
capabilities = ... 

} 

> 

ContentPath = { 

source = "foo.server.com" 
destination = "foo.user.com" 
protocol = ... 
num_nodes = 2 
nodes[0] = { 

hostname = "foo5.bar.com" 

capabilities = ... 

> 

nodes[1] = { 

hostname = "foo6.bar.com" 
capabilities = ... 
} 

} 
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